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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document provides the description of the Packet Data Convergence Protocol (PDCP). 
PDCP provides its services to the NAS at the UE or the relay at the Radio Network Controller (RNC). 
PDCP uses the services provided by the Radio Link Control (RLC) sublayer. 
The main functions of PDCP are: 

compression of redundant Network PDU control information (header compression); 

transfer of packet data protocol user data using services provided by RLC protocol. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 25.401: "UTRAN Overall Description". 

[2] 3GPP TR 2L905: "3G Vocabulary". 

[3] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[4] 3GPP TS 25.303: "Interlayer Procedures in Connected Mode". 

[5] 3GPP TS 25.322: "RLC Protocol Specification". 

[6] IETF RFC 2507: "IP Header Compression". 

[7] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[8] IETF RFC 3095: "RObust Header Compression (ROHC): Framework and four profiles: RTP, 

UDP, ESP, and uncompressed". 

[9] IETF RFC 3096: "Requirements for robust IP/UDP/RTP header compression" . 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AS Access Stratum 

CID Context Identifier 

C-SAP Control Service Access Point 

IETF Internet Engineering Task Force 

IP Internet Protocol 

L2 Layer 2 (data link layer) 

L3 Layer 3 (network layer) 

NAS Non Access Stratum 

PDCP Packet Data Convergence Protocol 
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PDU Protocol Data Unit 

FID Packet Identifier 

RB Radio Bearer 

RFC Request For Comments 

RLC Radio Link Control 

ROHC RObust Header Compression 

RTF Real Time Frotocol 

SDU Service Data Unit 

TCF Transmission Control Frotocol 

UDF User Datagram Frotocol 

UE User Equipment 

UMTS Universal Mobile Telecommunications System 

UTRA UMTS Terrestrial Radio Access 

UTRAN UMTS Terrestrial Radio Access Network 



4 General 

4.1 Objective 

The present document describes the functionality of the UTRAN FDCF. The overall UTRAN logical architecture is 
defined in [3]. 

Network layer protocols are intended to be capable of operating over services derived from a wide variety of 
subnetworks and data links. UMTS supports several network layer protocols providing protocol transparency for the 
users of the service. At that point of view supported protocols are IFv4 and IFv6. Introduction of new network layer 
protocols to be transferred over UTRAN shall be possible without any changes to UTRAN protocols. Therefore, all 
functions related to transfer of packets from higher layers (FDCF SDUs) shall be carried out in a transparent way by the 
UTRAN network entities. This is one of the requirements for UTRAN FDCF. 

Another requirement for the FDCF is to provide functions that help to improve channel efficiency. This requirement is 
fulfilled by the possibility to implement different kinds of optimisation methods. The currently known methods are 
standardised IETF header compression protocols. 

Every RB is connected to one FDCF entity and one FDCF entity is connected to one RLC entity. The FDCF entities are 
located in the FDCF sublayer. 

Every FDCF entity uses zero, one or several header compression protocol types with certain parameters. Several FDCF 
entities may use the same protocol type. The protocol types and their parameters are negotiated by higher layers and 
indicated to FDCF through the FDCF Control Service Access Foint (FDCF-C-SAF). 

Since the adaptation of different network layer protocols to FDCF is implementation dependent, it is not defined in the 
present document. 

4.2 Overview on sublayer architecture 

Figure 1 shows the model of the FDCF within the UTRAN protocol architecture. Every FDCF-SAF uses exactly one 
FDCF entity. Each FDCF entity uses none, one or several header compression protocol types. 
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Figure 1 : PDCP structure 

Figure 1 represents only one possible structure for PDCP and this should not restrict implementation. However, 
subclause 5.1 shall be adhered to. 



Functions 



Packet Data Convergence Protocol shall perform the following functions: 

- header compression and decompression of IP data streams (e.g., TCP/IP and RTP/UDP/IP headers) at the 
transmitting and receiving entity, respectively. The header compression method is specific to the particular 
network layer, transport layer or upper layer protocol combinations e.g. TCP/IP and RTP/UDP/IP 

transfer of user data. Transmission of user data means that PDCP receives PDCP SDU from the NAS and 
forwards it to the RLC layer and vice versa 

maintenance of PDCP sequence numbers for radio bearers that are configured to support lossless SRNS 
relocation 



5.1 Header Compression 



The header compression method is specific for each network layer protocol type. The network layer protocol type is 
indicated during PDP context activation as defined in [7]. The header compression protocols and their parameters are 
configured by higher layers for each PDCP entity and indicated to PDCP through the PDCP-C-SAP. Compressor and 
decompressor initiated signalling between peer PDCP entities, during operation, is carried out in the user plane. 

The PDCP layer shall be able to support several header compression protocols and it shall always be possible to extend 
the list of supported protocols in the future. 
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The PDCP layer can have one or several PDCP entities. Each PDCP entity may use zero, one, or several header 
compression protocols. It shall be possible to establish several header compression protocols of different types related to 
one PDCP entity. Different PDCP entities may include header compression protocols of the same type. 

Figure 1 shows an example how PDCP may be configured. 

5.1.1 Assignment of PID values 

PDCP shall be able to distinguish different types of header compression packets to handle them with a correct header 
compression protocol and furthermore to indicate the type of the packet within a certain protocol. This is realised by 
utilising the PID field in the PDU structure. 

PDCP shall be able to: 

identify different types of header compression protocols 

identify different header compression protocol packet types and 

identify different contexts for a header compression protocol 

The requirements above are realised by utilising the PID field in the PDCP PDU format. 

The following table illustrates an example of the PID value allocation table when five arbitrary header compression 
methods (RFC 2507[6], Methods A and B, Method C and RFC 3095 [8]) are configured for one PDCP entity. The table 
is reconfigured every time the PDCP entity is reconfigured with a change in the supported header compression 
protocols. 

Table 1 : Example of the PID value allocation table 



PID 
Value 


Optimisation method 


Packet type 





No header compression 


- 


1 


RFC 2507 


Full header 


2 


RFC 2507 


Compressed TCP 


3 


RFC 2507 


Compressed TCP nondelta 


4 


RFC 2507 


Compressed non TCP 


5 


RFC 2507 


Context state 


6 


Method A 


Uncompressed TCP/IP 


7 


Method A 


Compressed TCP/IP 


8 


Method B 


Uncompressed IP/UDP/RTP 


9 


Method B 


Compressed IP/UDP/RTP 


10 


RFC 3095 


CIDO 


11 


RFC 3095 


CID1 


12 


RFC 3095 


CID2 


13 


Method C 


Full header 


14 


Method C 


Compressed header 


15.. .31 


Unassigned value 


- 



The assignment of the PID values follow the general rules listed below: 

PID value is reserved permanently for no compression; 

PID values are assigned in ascending order, starting from 1 ; 

PID values are assigned independently to each PDCP entity; 

PID values are reassigned for the PDCP entity after renegotiation of the header compression protocols; 

the list of negotiated (or re-negotiated) header compression entities shall be examined, starting from the first one 
in the list. The number of PID values to be assigned is specified in the subclause for this protocol; 

if there are not enough unused PID values to be assigned to a header compression protocol, the negotiated header 
compression entities using this protocol shall be ignored without error notification; 

PID values that are used and are not defined invalidate the PDCP PDU; 
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for a certain protocol in a PDCP entity the assignment of PID values starts from (n+1) where n is the number of 
PID values already assigned to other protocols. The assignment is done in the order the protocols are configured 
by higher layers. In the example given in table 1, RFC 2507 was the first, Method A the second, Method B the 
third. RFC 3095 the fourth and Method C the fifth protocol configured by higher layers. The PID assignment 
shall follow this order. 

The used header compression protocol, the header compression packet type and header compression protocol contexts 
are unambiguously known by the basis of the PID value and shall apply to peer PDCP entities. While transferring data, 
the PID values are conveyed in the field of the PDCP header belonging to the PDCP PDU. Any successfully configured 
header compression protocol may be used for header compression of a PDCP SDU. 

5.1 .2 IP Header Compression (RFC 2507) 

The detailed operation of the "IP Header Compression" protocol is described in clause 3 of the IETF specification 
RFC 2507 [6]. Furthermore the mechanisms related to error recovery and packet reordering are described in clauses 10 
and 1 1 of the RFC 2507. These mechanisms shall be included in the functionality of the header compression supported 
by PDCP. 

5.1 .2.1 Context identifiers 

Context identifiers for RFC 2507 shall only be included in the RFC 2507 packet types, as defined in [6]. 



5.1.2.2 



Assignment of PID values for RFC 2507 



The following PID values shall be assigned to the RFC 2507 header compression in the order presented in the table 
where n is the number of PID values already assigned to other protocols. 

Table 2: PID values assigned to RFC 2507 header compression protocol 



PID value 


Optimisation method 


Packet type 


n+1 


RFC 2507 


Full header 


n+2 


RFC 2507 


Compressed TCP 


n+3 


RFC 2507 


Compressed TCP non-delta 


n+4 


RFC 2507 


Compressed non-TCP 


n+5 


RFC 2507 


Context state 



5.1 .3 Robust Header Compression (RFC 3095) 

The detailed operation of the, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, 
and uncompressed", protocol is described in the IETF specification RFC 3095 [8]. 



5.1.3.1 



Context identifiers 



The context of the RFC 3095 protocol is defined in [8]. RFC 3095 can only be configured to support one or several 
contexts. Each context is identified by a value known as the context identifier (CID). If CIDs are to be used, then the 
CID shall be: 

included in the PDCP header; or 

- included in the RFC 3095 packet format [8]. 

The choice of which of the above two methods to use is configured by upper layers. The assignment of the PID values 
is specified in subclauses 5.1.3.2 and 5.1.3.3, respectively. 



5.1.3.2 



Assignment of PID values for RFC 3095 with CIDs in PDCP PDU Header 



The following PID values shall be assigned to the RFC 3095 protocol in the order presented in the table where n is the 
number of PID values already assigned to other protocols. As shown in the Table 3 below, the allocation of PID values 
for the RFC 3095 map to the CID values used by RFC 3095. The maximum CID value (CIDx) is configured by upper 
layers. The RFC 3095 protocol shall not introduce CIDs in the ROHC packet format. 
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Table 3: PID values assigned to RFC 3095 header compression protocol 



PID value 


Optimisation method 


Packet type 


n+1 


RFC 3095 


CID1 


n+2 


RFC 3095 


CID2 




RFC 3095 






RFC 3095 




n+x 


RFC 3095 


CIDx 



5.1 .3.3 Assignment of PID values for RFC 3095 packet format 

The following PID value shall be assigned to the ROHC header compression as presented in the table where n is the 
number of PID values already assigned to other protocols. 

Table 4: PID values assigned to RFC 2507 header compression protocol 



PID value 


Optimisation method 


Packet type 


n+1 


RFC 3095 


RFC 3095 packet format 



The RFC 3095 protocol can be configured to handle CIDs within the ROHC packet format. In such a case, PDCP shall 
not be configured to accommodate ROHC CIDs in the PDCP PID, as described in subclause 5.1.3.1. 



5.1.3.4 



RFC 3095 Segmentation 



The RFC 3095 protocol supports segmentation. The segmentation can vary packet by packet and it does not cause any 
overhead to packets that are not segmented. The segmentation in RFC 3095 shall not be used when RFC 3095 uses the 
non-transparent mode of RLC [5], in which case the MRRU (maximum reconstructed reception unit) shall be equal to 
0. RFC 3095 segmentation shall only be used when RFC 3095 uses the transparent mode of RLC and the 
PACKET_SIZES_ ALLOWED is used to configure ROHC packet sizes. Furthermore, segmentation shall be applied if 
the produced packet does not fit to the largest packet as indicated by PACKET_SIZES_ALLOWED. 

5.1.3.5 Protocol Parameters 

RFC 3095 has two types of parameters [8] : 

configuration parameters: these are mandatory and must be configured between compressor and decompressor 
peers. 

implementation parameters: these are optional and, when used, stipulate how RFC 3095 operates. 

These parameters are categorized in four different groups, as defined below: 

M: Mandatory and configured by upper layers. 

MO: Parameters that must be supported and when used can only be configured or triggered by upper layers. 

O: Optional RFC 3095 parameters that are not configured by upper layers. They may be used locally (i.e. 
UTRAN and/or in UE) for RFC 3095. 

- N/A: These are not used in RFC 3095. 

The usage and definition of the parameters shall be as specified below. 

MAX_CID (M): This is the maximum CID value that can be used. One CID value shall always be reserved for 
uncompressed flows. 

LARGE_CIDS: This is not configured by upper layers but inferred from the configured value of MAX_CID 
according to the following rule: 

If MAX CID > 15 then LARGE CIDS = TRUE else LARGE CIDS = FALSE. 
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PROFILES (M): Profiles are used to define which profiles are allowed to be used by the UE in uplink. All 
profiles defined in [8] shall be supported by the UE. 

FEEDBACK_FOR (N/A): 

MRRU (M): Segmentation is not used by default. 

NO_OF_PACKET_SIZES_ALLOWED (O) 

PACKET_SIZES_ALLOWED (MO): This parameter, if configured, governs which packet sizes in bytes may be 
used by RFC 3095. Thus, packet sizes not in the set of values for this parameter shall not be used. 

PAYLOAD_SIZES (O) 

NO_OF_PACKET_SIZES_USED (O) 

PACKET_SIZES_USED (O) 

CONTEXT_REINITIALIZATION (MO) 

MODE (O) 

CLOCK_RESOLUTION (O) 

REVERSE_DECOMPRESSION_DEPTH (M): Default value is that reverse decompression is not used. 



5.2 



Void 



5.3 



Data Transfer 



5.3.1 Data transfer over acknowledged mode RLC 

If header compression is negotiated the PDCP entity shall perform header compression upon reception of a 
PDCP-DATA.Req. The PDCP-PDU is then delivered in RLC-AM-DATA.Req to RLC. 

During operation, when the peer PDCP entity receives the PDCP-PDU in a RLC-AM-DATA.Ind primitive, the PDCP 
entity shall perform the header decompression (if negotiated) of PDCP-PDU to obtain the PDCP SDU and deliver the 
PDCP SDU to the PDCP user with the PDCP-DATA.Ind. The following figure illustrates data transfer over 
acknowledged mode RLC. 



Originator 



PDCP user 



PDCP 



PDCP-DATA.req 
► 



RLC 



RLC-AM-DATA.req 
► 



RLC-AM-DATA.cnf 
< 



Receiver 



RLC 



Acknowledgement 
< 



PDCP 



RLC-AM-DATA.ind 
► 



PDCP user 



PDCP-DATA.ind 
► 



Figure 2: PDCP data transfer over acknowledged mode RLC 
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5.3.2 Data transfer over unacknowledged and transparent mode RLC 

If header compression is negotiated the PDCP entity shall perform header compression upon reception of a 
PDCP-DATA.Req. The PDCP-PDU is then delivered in RLC-UM-DATA.Req or RLC-Tr-DATA.Req to RLC. 

When the peer PDCP entity receives the PDCP-PDU in the RLC-UM-DATA.Ind or RLC-Tr-DATA .Ind primitive, the 
PDCP entity shall perform the header decompression (if negotiated) of PDCP-PDU to obtain the PDCP SDU and 
deliver the PDCP SDU to the PDCP user with the PDCP-DATA.Ind. The following figure illustrates data transfer over 
unacknowledged and transparent mode RLC. 
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Figure 3: PDCP data transfer over unacknowledged or transparent mode RLC 



5.4 



SRNS Relocation 



Lossless SRNS relocation is only applicable when RLC is in in-sequence delivery and acknowledged mode PDCP will 
only support lossless SRNS relocation if it is 'capable' of doing so. This is indicated by upper layers. 

The PDCP layer shall, for those radio bearers that are configured to support lossless SRNS relocation: 

support PDCP sequence numbering as specified in subclause 5.4. L 

The PDCP layer shall carry out the following during lossless SRNS relocation: 

- provide unconfirmed PDCP SDUs and sequence numbers for forwarding to the target RNC 

For each radio bearer, the Receive PDCP Sequence Number of the next PDCP SDU expected to be received is 
transferred from the source to target SRNC. For each radio bearer the source SRNC forwards to the target SRNC the 
downlink PDCP-SDUs. Source SRNC provides the Send PDCP sequence number of the first PDCP SDU to be 
forwarded to the target SRNC. 

The target SRNC shall send to the UE the next expected UL Receive PDCP Sequence Number. The UE shall send to 
the target SRNC the DL Receive PDCP Sequence Number of the next expected PDCP SDU. The successfully 
transmitted PDCP SDUs are thus confirmed. More detailed descriptions of this procedure can be found in [4] and [7]. 

The reset of all compression entities, for an RB, shall be made during SRNS relocation. Header compression is still 
possible during relocation. Negotiated compression parameters remain valid during reset, but all state information is 
initialised, e.g. header compression contexts. Therefore, in header compression case, the first 'compressed' packet is a 
full header. For later releases of this specification, it may be considered not to reset the PDCP entity, internal protocol 
information, i.e. states and header compression contexts, but to forward these from the source SRNC to target SRNC. 
Header compression for a PDCP entity can then continue from the state that it had directly before SRNS relocation. 

5.4.1 PDCP Sequence Numbering 

PDCP sequence numbering is only applicable when lossless SRNS relocation is to be supported. The value of the PDCP 
sequence number ranges from to 65535. The PDCP SN window size indicates the maximum number of PDCP PDUs 
that can be numbered at any given time. The PDCP SN window size is negotiated by upper layers. When the PDCP 
entity is setup for the first time for the PDCP user the PDCP sequence numbers are initialised to zero. 

For each radio bearer: 
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a value of the UL_Send PDCP sequence number is associated with each sent PDCP-PDU in the UE. The 
UL_Send PDCP sequence number is set to zero for the first sent PDCP PDU. The UL_Send PDCP sequence 
number is incremented by one when a PDCP PDU is deUvered to RLC; 

a value of the DL_Send PDCP sequence number is associated with each sent PDCP-PDU in UTRAN. The 
DL_Send PDCP sequence number is set to zero for the first sent PDCP PDU. The DL_Send PDCP sequence 
number is incremented by one when a PDCP PDU is delivered to RLC; 

a value of the UL_Receive PDCP sequence number is associated with each received PDCP-PDU in UTRAN. 
The UL_Receive PDCP sequence number is set to zero for the first received PDCP PDU. The UL_Receive 
PDCP sequence number is incremented by one when a PDCP Data PDU is received from RLC or is incremented 
by one for each discarded RLC SDU, as indicated by the RLC SDU Discard function [5]; 

a value of the DL_Receive PDCP sequence number is associated with each received PDCP-PDU in the UE. The 
DL_Receive PDCP sequence number is set to zero for the first received PDCP PDU. The DL_Receive PDCP 
sequence number is incremented by one when a PDCP Data PDU is received from RLC or is incremented by one 
for each discarded RLC SDU, as indicated by the RLC SDU Discard function [5]. 

PDCP sequence numbers are never decremented in the PDCP Tx. 

PDCP SeqNum PDUs shall be sent by the peer PDCP entities when synchronization of the PDCP SN is required. It 
shall only be used for radio bearers that support or are configured / reconfigured to support lossless SRNS relocation. 
Synchronization of PDCP SN is required after RLC reset, RB reconfiguration or reception of invalid next expected 
UL/DL Receive PDCP Sequence Number after relocation. 

When a PDCP entity receives a PDCP SeqNum PDU, the receive PDCP sequence number (i.e. UL_Receive or 
DL_Receive) shall be set to the value indicated in the PDCP SeqNum PDU. 

PDCP SeqNum PDUs shall not be delivered to RLC after RLC has confirmed the successful transmission of a RLC 
SDU that contained a numbered PDCP PDU. 



6 Services 

6.1 Services provided to upper layers 

The following services are provided by PDCP to upper layers: 
- PDCP SDU delivery. 

6.2 Services expected from RLC layer 

For a detailed description of the following functions see [5]. 
Data transfer in acknowledged mode. 
Data transfer in unacknowledged mode. 
Data transfer in transparent mode. 
Segmentation and reassembly. 
In-Sequence delivery. 



7 Elements for layer-to-layer communication 

The interaction between the PDCP layer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the PDCP layer and other layers. The primitives shall 
not specify or constrain implementations. 
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7.1 Primitives between PDCP and upper layers 

The primitives between PDCP and upper layers are shown in table 5. 

Table 5: Primitives between PDCP and upper layers 



Generic Name 


Parameter 


Req. 


Ind. 


Resp. 


Conf. 


PDCP-DATA 


Data 


Data 


Not Defined 


Not Defined 


CPDCP-CONFIG 


PDCP-lnfo, RLC-SAP 
SN Sync 


Not Defined 


Not Defined 


Not Defined 


CPDCP-RELEASE 


RLC-SAP 


Not Defined 


Not Defined 


Not Defined 


CPDCP-SN 


PDCPSN 


Not Defined 


Not Defined 


Not Defined 


CPDCP-RELOC 


Receive_SN 


Not Defined 


Not Defined 


Receive SN, 
Send SN 



Each Primitive is defined as follows: 

a) PDCP-DATA-Req./Ind. 

PDCP-DATA-Req is used by upper user-plane protocol layers to request a transmission of upper layer PDU. 
PDCP-DATA-Ind is used to deliver PDCP SDU that has been received to upper user plane protocol layers. 

b) CPDCP-CONFIG-Req. 

CPDCP-CONFIG Req is used to configure and - in case of already existing PDCP entity - to reconfigure a 
PDCP entity and to assign it to the radio bearer associated with that entity. 

c) CPDCP-RELEASE-Req. 

CPDCP-RELEASE-Req is used by upper layers to release a PDCP entity. 

d) CPDCP-SN-Req. 

- CPDCP-SN-Req is used to transfer the PDCP SN to PDCP. 

e) CPDCP-RELOC-Req/Conf. 

CPDCP-RELOC-Req initiates the SRNS relocation procedure in PDCP for those radio bearers that are 
configured to support lossless SRNS relocation. The Receive_SN is only included when the UE receives a 
new U-RNTI. 

- CPDCP-RELOC-Conf is used to transfer the Receive_SN and/or Send_SN to upper layers for lossless SRNS 
relocation. The Send_SN is only included at the source RNC. 

The following parameters are used in the primitives: 

1) PDCP-lnfo: 

contains the parameters for each of the header compression protocols configured to be used by one PDCP 
entity. 

2) RLC-SAP: 

- the RLC-SAP (Tr/UM/AM) used by PDCP entity when communicating with RLC sublayer. 

3) SN_Sync: 

- Indicates that PDCP should start PDCP sequence number synchronization 

4) Send_SN: 

The send PDCP sequence number of the next PDCP PDU to be sent. There is one in the uplink 
(UL_Send_SN) and one in the downhnk (DL_Send_SN). Refer to subclause 5.4.1. 

5) Receive_SN: 
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The receive PDCP sequence number of the next PDCP PDU expected to be received. There is one in the 
upUnk (UL_Receive_SN) and one in the downlink (DL_Receive_SN). Refer to subclause 5.4.1. 

6) PDCPSN: 

This includes a PDCP sequence number. 



8 Elements for peer-to-peer communication 

8.1 Protocol data units 

Different protocol data unit formats are defined in PDCP, one not introducing any overhead to the (compressed) PDCP 
SDU, others introducing such overhead. Whether overhead is introduced by the PDCP protocol is configured for the 
PDCP entity by higher layers. 

8.2 Formats 

A PDCP PDU is byte-aligned, if the RLC is run on unacknowledged or acknowledged mode. Otherwise, in transparent 
mode, it is bit-aligned. In the drawings in subclause 8.2, bit strings are represented by tables in which the first bit is the 
leftmost one on the first line of the table, the last bit is the rightmost on the last line of the table, and more generally the 
bit string is to be read from left to right and then in the reading order of the lines. 

SDUs are bit strings, with any non-null length. If not compressed within PDCP an SDU is included from first bit 
onward. 

8.2.1 PDCP-No-Header PDU 

The PDCP-No-Header PDU does not introduce any overhead to the PDCP SDU. 
The format of the PDCP-No-Header-PDU is shown in table 6. 

Table 6: PDCP-No-Header PDU 



Data 



8.2.2 PDCP Data PDU 

The data PDU is used to convey a payload unit containing a PDCP SDU, header compression related control signalling 
or data that has been obtained from PDCP SDU after header compression. 

The format of the PDCP-Data-PDU is shown in table 7. 

Table 7: PDCP-Data-PDU format 



PDU type 



PID 



Data 



8.2.3 PDCP SeqNum PDU 



The sequence number PDU is used to convey a payload unit containing a PDCP PDU sequence number and PDCP 
SDU, header compression related control signalling or data that has been obtained from PDCP SDU after header 
compression. 
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The format of the PDCP-SeqNum-PDU is shown in table 8. 

Table 8: PDCP-SeqNum-PDU format 



PDU type 



PID 



Sequence number 



Data 



8.3 



Parameters 



If not otherwise mentioned in the definition of each field then the bits in the parameters shall be interpreted as follows: 
the left most bit string is the first and most significant and the right most bit is the last and least significant bit. 

Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases the 
bits appear ordered from MSB to LSB when read in the PDU. 

8.3.1 PDU Type 

Length: 3 bits. 

The PDU type field indicates the PDCP-data-PDU type. 



Bit 


PDU Type 


000 


RID field used for header compression information (PDCP-PDU 
format described in table 5) 


001 


PID field used for header compression information and the PDCP 
PDU sequence number included (PDCP-PDU format described in 
table 6) 


010-111 


Reserved (PDUs with this encoding are invalid for this version of the 
protocol) 



8.3.2 PID 

Length: 5 bits. 

The PID field indicates the used header compression packet type or a context identifier. 



Bit 


Description 


00000 


No header compression 


00001-11111 


Dynamically negotiated header compression identifier, as described 
in subclause 5.1.1 



The PID field value defines the used header compression type and packet type. One compression protocol may reserve a 
certain amount of values from the PID field value space for different packet types. The receiving PDCP entity makes 
the reverse operation (i.e. header decompression) according to the PID field value. There is no fixed relationship 
between the PID field value and the used optimisation / packet type, but PID field values are defined dynamically at the 
PDCP parameter negotiation. 

The PID field can also be used to represent context identifier values, as illustrated in subclause 5. LI. 

8.3.3 Data 

PDCP SDUs that have been header compressed are mapped to this field if header compression is negotiated. Otherwise, 
PDCP SDUs are mapped to this field. 
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9 Handling of unknown, unforeseen and erroneous 

protocol data 

In case of error situations the following action is foreseen: 
1) PDCP entity should discard invahd PDU. 
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